In computer systems, a number of different levels of system functionality must be provided.
The highest degree of functionality, hereinafter referred to as ON functionality, is obtained when the operating system for the computer has been loaded. At times when the operating system is running and accessible, application programs layered on top of the operating system can be executed. It is expected that the computer system will be operating in this state, hereinafter referred to as the ON state, the vast majority of time.
An intermediate level of functionality is provided at times when the operating system is not being accessed. This degree of functionality will hereinafter be referred to as console functionality.
When the console functionality of the computer system is being utilized, it is possible to perform a number of operations related to the management, maintenance, and/or debug of the computer system. For example, console functionality allows the user to load and run code that does not require access to the operating system. Therefore, standalone diagnostic programs can be executed.
At times when the computer system cannot access the operating system without first booting up the operating system, the computer system is in a state that will be referred to as console state. At a minimum, the computer system hardware and software that is operational in console state must be sufficient to allow the user to bootstrap load the operating system.
Finally, the lowest degree of computer system functionality, hereinafter referred to as front panel functionality, is supplied by hardware and software that enable the system to provide console functionality. At a minimum, front panel functionality is required in order to power up the system.
Front panel functionality also may include certain basic management, maintenance, and debug operations. For example, hardware and software may be provided to determine whether there are faults in the computer system that prevent the use of console functionality. The computer system also may contain switches or flags that are set by the user (or preset by the manufacturer) in order to select among a number of options, including options relating to system behavior during initialization or relating to security measures to limit access to console functionality. This option selection is generally implemented in larger computer systems by physically setting a number of switches located on a front panel, and in smaller computer systems by setting a number of flag bits in devices such as EEPROMs.
Console functionality can be implemented in a number of different ways. In some computer systems, such as the MicroVAX, a single microprocessor is used to execute instructions that provide console functionality at some times and also to execute instructions that provide ON functionality at other times. In these systems, a ROM is provided that has memory addresses which are reserved for the storage of console code and which are separate from the memory addresses used to store code that is executed at times when the operating system is being accessed.
In other computer systems, such as the Digital VAX 8600 and VAX 8800, console functionality is provided by a console subsystem that is relatively independent from the hardware and software used to provide ON functionality. In these systems, a separate microprocessor that does not access the operating system is used to execute console code at all times, and may be housed in a separate cabinet from the main processor. The console subsystem also may include its own main memory, mass storage devices, and video terminal.
Unfortunately, in existing computer systems that provide management, maintenance, and/or debugging capabilities, there are problems and inefficiencies in the ways in which console functionality is implemented.
One of the main problems with existing implementations is the inability to access the console functionality of a computer system from a remote location. Traditionally, console code, which is executed without accessing the operating system, has only been available to users with local access to the computer system.
In existing console subsystems, a local interface may be used that is not well-suited for remote access. Local access to the console functionality of a computer system typically is provided by a human interface in the form of selectable switches, indicator lights, and/or text that is input via a keyboard and output via a CRT monitor. Text-based input/output is unsuitable for transfers between remote locations on a standard network interconnection for a number of reasons: (1) It is difficult for a program to parse text that is intended for human interpretation; (2) Human-readable text is not an efficient information transfer mechanism; and (3) Character-oriented input/output is not an efficient means of information transfer.
In some console subsystems, the consoles associated with a number of computer systems in a network may be coupled to each other. However, the communication between these consoles is completely separate and independent from the communication between the computer systems over the network.
In these console subsystems, the standard network interconnection cannot be used to access the console functionality of a computer system from a remote location. Instead, a separate link is set up that is dedicated to communication between the consoles, and a special interface has to be included in these consoles. As a result, existing hardware and software for providing the interface between a computer system and a standard network interconnection cannot be used to implement the interface required for console-to-console communication.
Typically, communication by a computer system over a standard network interconnection is accomplished by network support hardware and software. Generally, this network support hardware and software operates by accessing the operating system of the computer system. Therefore, the management of distributed computer systems in a network from a remote location may be difficult at times when those systems are not accessing or cannot access their operating systems.
For example, if a hardware or software fault prevents a computer system from using its operating system, maintenance and/or debug of the system may have to be performed locally. As a result, users at each computer system site in the network may need standalone diagnostic programs that are sufficient to independently maintain and/or debug each of their own systems.
Furthermore, it may be necessary for users at each computer system site to have considerable expertise in the isolation of and recovery from faults. Otherwise, whenever one of the computer systems fails, i.e., "hangs up" or "crashes," trained field service personnel would have to be sent to that computer system site in order to diagnose any problems.
As a result of this inability to access the console functionality of a computer system from a remote location, one computer system in a network cannot use a standard network interconnection to, for example, force the hardware and software in another node to bootstrap load its operating system, or to load and execute a standalone diagnostic program. However, there is a need to have the capability of using the standard network interconnection to reboot an operating system into a remote computer system without physically visiting that computer system.
For example, if one computer system in a network is in an unknown state as a result of a system hang up or crash, it may be desirable to send over the standard network interconnection, from a console "client" at a remote location, a request that the malfunctioning computer system reboot the operating system. In this way, the malfunctioning computer system is forced into a known state.
The lack of remote access to console functionality also prevents implementation of other performance and efficiency improvements. For example, it is not efficient to provide a dedicated group of resources coupled to the standard network interconnection for touring the computer systems in the network on a periodic basis for the purpose of understanding the status of those systems in which the operating systems are not booted up and running.
If remote access to console functionality over the standard network interconnection were made available, console functionality could be implemented by performing many of the required console operations in a special-purpose computer system in the network, referred to as a console concentrator. The console concentrator would act as a console client and send requests for performance of console functions over the standard network interconnection. The other computer systems in the network would act as console "servers" that perform console functions in response to requests made by console clients.
Several advantages may be gained if the execution of many console operations is concentrated in one of the computer systems in a network. The computer system acting as the console concentrator can be adapted to include hardware and software especially designed for the management, maintenance, and/or debugging of other computer systems in the network. For example, artificial intelligence and/or expert systems could be incorporated in the console concentrator in order to diagnose problems occurring in other computer systems.
As a result, operators and/or service personnel at the console concentrator may be provided with a clearer picture of the status of other computer systems in the network. Additionally, it may be easier to protect the confidentiality of the hardware and software used to manage, maintain, and debug computer systems if the diagnostic programs are completely or partially stored and/or executed at the console concentrator.
Furthermore, if many console operations are performed by a sophisticated concentrator acting as a console client, the hardware and software in the concentrator may be updated to take into account the requirements of various computer systems coupled to the network as the features incorporated in those systems change. It may be beneficial to provide a single point in a network at which multiple computer systems can be managed. Such an approach may eliminate any need to separately upgrade a number of computer systems when revisions are made in the computer systems themselves or in the procedures used for management, maintenance, and debugging.
At present, each time a new processor is developed, it often becomes necessary to organize a dedicated console development team to design the console associated with that processor. However, it is wasteful to duplicate previous development efforts by recreating higher level functions related to console functionality, such as command processing, that have already been implemented in existing computer systems.
Correspondingly, if more complicated tasks are handled by a console concentrator, then the amount of hardware and software dedicated to execution of tasks related to console operations can be reduced in other computer systems in the network, which act as the console servers. Without a console concentrator, sufficient hardware and software may have to be distributed throughout the network to enable each system in the network to independently perform all operations necessary in order to support software that can effectively manage, maintain, and debug that computer system.
The division of tasks between a computer system functioning as a console client and other computer systems functioning as console servers would permit simplification and standardization of the console functionality implemented in the console server computer systems. As a result, when a new computer system is being developed, the amount of console functionality that must be included in that computer system can be minimized, making the development effort simpler.
Simplification of the console functionality provided by the console server computer systems in a network also may reduce the number and complexity of consoles that are required. The shifting of tasks to a computer system that functions as the console client may eliminate the need to provide certain console server computer systems with console subsystems that are located in separate cabinets and that have their own dedicated video terminals. Furthermore, simplification should make development efforts easier and faster. As a result, the cost of providing the console server computer systems may be reduced, and floor space requirements for these computer systems also may decrease.
Standardization of the console functionality provided by console server computer systems may reduce the variety of consoles that are required. Currently, there are inconsistencies in the interfaces provided by various consoles to users, thereby increasing the amount of training that is required for users and field service personnel. Furthermore, consoles may differ from each other in command processing, data presentation, and the effect of particular commands. As a result, a number of operator-induced errors occur, and errors may occur during the management and maintenance of the computer system.
Additional problems with existing console subsystems arise as a result of the automatic transition of a computer system from an ON state to a console state. Presently, when a request for access to console functionality is provided, the computer system changes to the console state. Therefore, in order to access the operating system again after entering the console state, the operating system may have to be rebooted.
However, it is inefficient to force a reboot of the operating system after each grant of access to console functionality. In some circumstances, the processor may be able to continue its operations after executing certain console functions. Therefore, there is a need for a system in which access to the operating system may be interrupted in response to a console function request when a computer system is in the ON state, and subsequently restarted after access to console functionality has been provided.